home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000068_icon-group-sender _Tue Mar 4 14:33:17 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 4 Mar 1997 14:44:43 MST
  2. Date: Tue, 4 Mar 1997 14:33:17 -0600
  3. Message-Id: <199703042033.OAA32615@ns1.cmpu.net>
  4. Mime-Version: 1.0
  5. Content-Type: text/plain
  6. Content-Transfer-Encoding: 7bit
  7. From: gep2@computek.net
  8. Subject: Re: Icon and two-dimensional matching
  9. To: icon-group@cs.arizona.edu
  10. X-Mailer: SPRY Mail Version: 04.00.06.17
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12. Status: RO
  13. Content-Length: 4250
  14.  
  15. >>SNOBOL4 absolutely DOES support substrings as a pseudovariable, as long as the 
  16. substring in question is the portion of the subject string that you're matching. 
  17. This, in fact, is the basis for ALL pattern matching in SNOBOL4!
  18.  
  19. >No, at least not in the sense that I'm speaking about.  Yes, it's possible 
  20. to replace a substring (assign to it) in the middle of a string, thus making 
  21. a string replacement statement a form of assignment.  
  22.  
  23. Right... in essence, you're using a "pseudovariable", replacing a specified 
  24. substring in a subject string, in an assignment statement.  This is one very 
  25. reasonable definition for a pseudovariable (okay, I agree that the syntax is a 
  26. little different than would be done in other languages, but anyhow that's 
  27. typical for S-BOL in a lot of ways!)
  28.  
  29. >But that alone 
  30. does not make a substring, either identified through pattern matching 
  31. or using SUBSTR into a pseudovariable; one can't form the NAME of any 
  32. sort of expression including a substring -- that's reserved to variables -- 
  33.  
  34. It's pretty trivial to evaluate the string value of the substring and put that 
  35. into a variable.
  36.  
  37. >to pass it as an argument IN SITU to a called function for example.  
  38.  
  39. Okay, but it's certainly easy enough to pass the VALUE to a called function in 
  40. S-BOL (okay, not in SIL SNOBOL4):
  41.  
  42.     func(p1,(str ? pattern),p3)
  43.  
  44. Admittedly that wouldn't allow modifying the substring in place from within the 
  45. function.
  46.  
  47. >Passing cross-sections of arrays to a routine is a bit more interesting in 
  48. Algol 68 than in PL/I; 
  49.  
  50. I *do* think it curious that Algol (and particularly Burroughs Extended Algol, 
  51. which was very highly regarded by those friends who used it back when I was at 
  52. the University of Illinois) seems to have really disappeared as a language for 
  53. current development.  At the time, I used PL/1 quite heavily, and liked the 
  54. language a lot.  I think I would enjoy having a good PL/1 compiler for my PC, 
  55. although I'm not really certain right at this instant what specific things I 
  56. would do with it if I had it... perhaps mostly for nostalgia value, but I think 
  57. I'd find stuff to do with it.
  58.  
  59. >>>I'm interested in generalized macro processing, where the macro 
  60. >processing becomes a method - a dynamic method - of program 
  61. >language development, and that plays just as much a part in program 
  62. >development as algorithm design, module design and data structure
  63. >design.  One specifies the TRANSLATION of algorithms, data 
  64. >specifications, ... into code.  Previous passes over the text or previous 
  65. >work in the same pass where rescanning is allowed, besides perhaps 
  66. >transforming the text, may decorate it with tokens (roughtly, a structure 
  67. >containing a source string and other information), or with trees or with 
  68. >other structures and with other information.  Then one has to recognize 
  69. >patterns among the tag-along information and source text, and to 
  70. >process it both by generating new information and transforming the 
  71. >structures and data that exist.
  72.  
  73. >>One of the shortcomings of Icon (compared with S-BOL), IMO, is that Icon 
  74. >supports neither EVAL() nor CODE().  Admittedly these are features that one 
  75. >doesn't use often in most S-BOL programs, but when you -do- need them, they
  76. are absolutely indispensable!
  77.  
  78. >Right !
  79.  
  80. >>In the case in question, you could use the full features of S-BOL to modify
  81. the 
  82. >program itself at source level, and to replace almost any desired part of it 
  83. >with an "enhanced" version during program execution... even in the middle of a 
  84. >statement!
  85.  
  86. >Right, but I'm considering general macro processing, and trying to avoid fixing 
  87. it to any one language or compiler, even though for what I'm doing, there
  88. has to be a base language for the macro stuff.
  89.  
  90. Obviously.  I think that a language like S-BOL would be ideal for macro 
  91. processing, due to the intrinsic features in the language.  Part of what makes 
  92. it *especially* interesting is the ability to have the S-BOL macro processor 
  93. PERMANENTLY augment its own features by adding code and using SAVE() to update 
  94. its own code file with new features... allowing for a kind of persistence which 
  95. is very difficult, I think, to do with other languages (even Icon) as a base.
  96.  
  97. Gordon Peterson
  98. http://www.computek.net/public/gep2/
  99.  
  100.